Enhanced Directory Assistance Services in a Telecommunications Network

ABSTRACT

Directory assistance provides telephone number look up services to callers based on the business or caller name as listed in a telephone directory. As such, directory assistance in the prior art provides a value-added service to telephone users and an expense that must be charged back to telephone subscribers or absorbed by telephone carriers. The present invention provides a method and system whereby directory assistance is enhanced to deliver a targeted advertising service to telephone listing owners and advertisers. The enhanced directory assistance (EDA) service of the present invention becomes an additional revenue source for carriers. The present invention also provides a method and system for dynamically ordering these directory listings and tracking subsequent telephone referrals.

RELATED APPLICATION INFORMATION

This application claims priority from U.S. Provisional PatentApplication No. 60/385,955 filed Jun. 3, 2002 and which is incorporatedherein by reference.

NOTICE OF COPYRIGHTS AND TRADE DRESS

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. This patent document may showand/or describe matter which is or may become trade dress of the owner.The copyright and trade dress owner has no objection to the facsimilereproduction by any one of the patent disclosure as it appears in thePatent and Trademark Office patent files or records, but otherwisereserves all copyright and trade dress rights whatsoever.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to the field of telecommunications, andparticularly to providing advertising opportunities in directoryassistance systems.

2. Description of Related Art

Telephone Directory Assistance has been around as long as there havebeen telephone operators. Once the number of telephone subscribersreached two and three digits, telephone directories were published asservice to the large numbers of telephone subscribers. These publishedtelephone directories or books helped both the subscribers and telephoneoperators locate and contact other telephone subscribers.

There are two types of telephone directories. The White Page-styleddirectory lists basic telephone contact information for all telephonesubscribers; basic listings are free to all subscribers and subscribersare listed by name. The Yellow Page-styled directory lists products andservices by category, to be included in a Yellow Page directory anadvertiser must pay a fee. The Yellow Page directory advertiser pays forboth the size of the advertisement or listing and for its inclusion inone or more specific categories.

Traditional directory assistance service provides telephone number lookup to the White Page style directory. Enhanced directory assistanceservice provides look up to a Yellow Page style directory. Thedifference between the two is based on how a caller finds a particulardirectory listing.

In a traditional directory assistance service, the caller contacts adirectory assistance operator and gives the operator the name of abusiness or person and its associated locale. The directory assistanceoperator then searches a telephone directory database for a telephonelisting that matches the sought-after criteria. Upon finding a match ora set of matches, the operator informs the caller and either getsfurther information to narrow the results or offers to connect thecaller to a desired telephone number.

In an enhanced directory assistance system, a caller contacts adirectory assistance operator and in addition to providing as somelocalization information to narrow where the caller wishes to find theproduct or services, the caller provides a category name or keywordassociated with the desired product or service. In the present art, anenhanced directory assistance operator then takes the providedinformation and searches or queries a Yellow Page-styled directory. Uponfinding a match, the operator informs the caller and either gets furtherinformation to narrow the results or offers to connect the caller to thedesired telephone number.

In the present art, inclusion in these paid listings is offered to abusiness or organization through monthly or yearly subscription fees.Also in the present art, listing partners can pay a premium fee to belisted at the top of a category or keyword lookup result list. Thepremium or preferred listing is given priority treatment by thedirectory assistance operator and mentioned before any other paidlistings are communicated.

Several problems are presented by the current art in respect to makingtelephone number look up a profitable business venture.

In systems that use keywords to classify products and services, thekeywords are determined independently from the business ownersthemselves. For instance, many directory assistance systems derive theirkeywords and classification from the government supplied StandardIndustrial Code (SIC) system or something similar. This type ofclassification system, while being widely adopted, is also slow tochange and adapt. Also, due to this inertia, the system does not offerenough granularity, meaning that a wide variety of products that arevery different may fall under a single classification. For instanceelectronic farm monitoring equipment might fall under same electronicscategory as portable music devices.

In the current art the order of the listings is determined byuncontrollable methods. For instance, if result listings are arrangedalphabetically, the only way to insure that your listing is included atthe top of a list—with the exception of the paying for premium highercost listings—is to change the name of the product or service.

DESCRIPTION OF THE DRAWINGS

FIG. 1 is a system block diagram of an Enhanced Directory AssistanceSystem utilizing human operators.

FIG. 1A is a system block diagram of an automated Enhanced DirectoryAssistance System.

FIG. 2 is a flow chart of the Enhanced Directory Assistance Systemoperation as seen from a caller's point of view.

FIG. 2A is flow chart of the automated Enhanced Directory AssistanceSystem operation as seen from a caller's point of view.

FIG. 3 is a system block diagram of an Enhanced Directory AssistanceOperator Position station.

FIG. 4 is a system block diagram of the Enhanced Directory AssistanceListing Management Server.

FIG. 5 is a system block diagram of the Enhanced Directory AssistanceListing Database.

FIG. 6 is a flow chart of the Get Listing Database operation.

FIG. 7 is a system block diagram of an Enhanced Directory AssistanceListing Distribution Server.

FIG. 8 is a flow chart of the Transaction Capture Block operation.

DETAILED DESCRIPTION OF THE INVENTION

Throughout this description, the embodiments and examples shown shouldbe considered as exemplars, rather than limitations on the apparatus andmethods of the present invention.

Enhanced Directory Assistance (EDA) services provide opportunities fortelephone listing owners and advertisers to promote their products andservices to telephone callers looking for the same products andservices. The EDA system disclosed here provides a method and systemwhereby directory assistance is enhanced to deliver a targetedadvertising service to telephone listing owners and advertisers.

In reference to FIG. 1, the illustration shows a preferredimplementation of a basic EDA service implementation. A telephonecustomer 10 connects to an EDA Center 20. An EDA operator position 30 atthe EDA Center processes the call with an EDA application console 31.The EDA application console connects to an Enhanced Directory AssistanceListing Management Server (LMSvr) 40 that contains a telephone listingData Storage System 41 and a telephone directory listing Query Processor42.

The EDA operator requests listing data from the LMSvr. The LMSvrreceives the request and dispatches results to the EDA ListingDistribution Server (LDSvr) 50. The LMSvr connects to an LDSvr thatcontains a Local Data Cache 51 and a Transaction Activity Collectionserver 52. The LDSvr caches or holds the results of a query. The resultsrepresent a set of telephone referral numbers that can be relayed to thetelephone customer.

If the telephone customer accepts a referral, that acceptance event isrecorded or captured and used for further business processing. Thebusiness processing may involve charge backs to listing owners oradvertisers, or storage of the query, results, and acceptance event forlater demographic analysis.

In reference to FIG. 1A, the illustration shows a preferredimplementation of an automated EDA service implementation. A telephonecustomer 500 connects to an EDA Center 510. An EDA Interactive VoiceRecognition (IVR) application 520 at the EDA Center processes the call.The IVR app is a Voice XML (VXML) application that recognizes andtranslates vocal utterances into computer requests. The EDA IVRapplication connects to a LMSvr) 526 that contains a telephone listingData Storage System 527 and a telephone directory listing QueryProcessor 528. The LMSvr connects to an EDA LDSvr 530 that operates asdescribed previously.

In a preferred implementation, the functions of the LMSvr and the LDSvrare combined in a single system.

In a preferred implementation, the single system is a SQL database and acollection of standard ANSI SQL procedures and SQL commands.

EDA Operational Flow

Referring to FIG. 2 unless otherwise indicated, the telephone customershown in FIG. 1-10 Initiates a DA Call 300 by dialing a predeterminednumber such as “411”. The telephone customer connects with the EDACenter FIG. 1-20 that assigns the call to an Enhanced DA Operator (EDAOp) position FIG. 1-30. The EDA Op picks up the inquiry and executes theGet Location 301 process. The EDA Op Requests a Location 302 from thecaller by asking “For What City?” The telephone customer responds with aLocation Response 304 such as “Los Angeles”.

In another preferred embodiment, the telephone customer connects withthe EDA Center by dialing a predetermined series of DTMF tones such as“* 711” or “## *”

In a preferred embodiment the Get Location process is automated. UsingAutomatic Number Identification (ANI) that is well known in the art acomputer system can detect the location of the calling partyautomatically. The detected code identifier can then be saved in acomputer variable for later use.

Next, the EDA Op executes the Get Keyword 309 process. The EDA OpRequests a Keyword 306 from the caller that describes that product orservice the caller is looking for. Keywords are words or phrases and canbe the actual name of the product or service such as “Marie Callender's”or a descriptive word or phrase that is associated with the product ofservice such as “strawberry pie”.

The caller responds with a Keyword Response 308 such as “Chineserestaurant”. The EDA Op processes the DA inquiry by inputting theinquiry at Query Entry 310.

In a preferred embodiment the Get Keyword process is automated. Usingtechnologies that are well known in the art such as Interactive VoiceRecognition (IVR) and standard voice application platforms such as VoiceXML (VXML), an automated dialogue obtains the desired keyword byrecognizing and translating the vocal utterance into a computerrecognized character string. The recognized keyword identifier can thenbe saved in a computer variable for later use.

EDA Operator Position Station

The EDA Op executes the Query Entry process through the EDA ApplicationConsole FIG. 1-31. As shown in FIG. 3, the EDA Operator Position stationcontains an input keyboard 66. The EDA Op 64 enters “Los Angeles” and“Chinese restaurant” on the input keyboard. The EDA application systemthen places data into an HTML Input Form 68 that is well known in theart.

Upon clicking on the HTTP form submit button, the EDA Applicationconverts the input form query to a message query. In a preferredimplementation, the message query is an XML document in the standard andwell-known XML format. The EDA Application sends the message querythrough a Network Connection 70 to the LMSvr FIG. 1-40 via the EDACenter FIG. 1-20.

The detailed operation of the LMSvr is disclosed in FIG. 4 and FIG. 5.The LMSvr processes the requested message query; any results arereturned through the network connection. The LMSvr accesses a datastorage system that contains business and directory listing data.

In a preferred implementation, the business and directory listing datais a database of products and services. The database containsdescriptive information, business owner or advertiser information andcontact phone numbers related to specific advertiser listings.

In the implementation, a message query processed by the LMSvr returns aset of listings, descriptions and phone numbers. The set is organized ina predetermined way and contains listings for a specified locale.

Keyword Processing

In a preferred implementation, the listings are organized by keywords.As is known in the art, a keyword is a descriptive word or phrase thatis used to classify or identify a product or service. In a telephonedirectory, a product or service has a title, description and phonenumber and is known as a listing. In the implementation each listing isassociated with one or a plurality of keywords.

In a preferred implementation, the LMSvr receives a query specifying akeyword and applies the query to a listing database server. Theoperation of such a database server is well known. The database serverreturns a set of listings related to the specified keywords.

The returned set of results are displayed on the console Data Display 72where the EDA Op can interpret and choose to continue to the next in theprocess and offer to refer the caller to a listing as shown in the OfferReferral Loop FIG. 2-313 process.

In a preferred implementation, the results are displayed in HTML tablesand HTML pages. In another preferred implementation, the set of resultsis returned as an XML document.

Referring once again to FIG. 2, the EDA Op executes a Read listing 314process, where listing descriptions are read to the customer one at atime in sequential order. In a preferred embodiment, the EDA Op mayplayback a recorded advertiser message rather than read the messagealoud. In another preferred embodiment, the EDA Application may employ atext-to-speech conversion unit to convert the advertiser message to asynthesized vocal audio message.

After each listing description is read or played back, the EDA Opexecutes the Offer Referral 316 process by asking “Connect to thisListing?” The customer may choose one of several options: “yes”—beconnected; or “no”—listen to the next listing description; or terminatethe call.

If the customer accepts, the Accept Referral 318 process begins and thecaller is connected to the listing owner's contact telephone number.Next the system initiates Transactions 320 where a series oftransactions linking the customer referral and the listing owner'saccounts are started.

If the customer does not accept, the next listing is read or played pack(if it exists), followed by the next Offer Referral step. Next, theprocess continues as above.

In the implementation, the result of the offer referral process is thecentral point of the disclosed targeted advertising process. The resultsgiven to the customer are targeted because they are the direct result ofa customer's search or inquiry.

If the customer accepts a referral, the owner of the referred listingincurs a monetary charge. The charge and all subsequent chargesrepresent a new revenue stream for the EDA service operators.

In a preferred implementation, this revenue stream can be shared betweentelecommunications operators, advertising intermediates and otherbusiness partners.

In a preferred implementation, the Offer Referral Loop process isautomated. Using well-known voice application technologies such as VXML,a multiple selection voice dialogue menu can execute the processeswithin this block.

EDA Listing Management Server

FIG. 4 shows a system block diagram of the EDA Listing Management Serverimplementation. An EDA query in the form of a query message is receivedat the EDA Listing Management Input 80 and sent to a Message Router andProcessor (MRP) 82.

In a preferred implementation, the query is an XML formattedcharacter-based message that is well known and well understood in theart. In a preferred implementation, the XML message is in the form of aSimple Object Access Protocol (SOAP) message format.

The MRP receives and processes a plurality of messages. The MRPdetermines what type of message is being processed, formats the messageparameters appropriately and adds additional processing data ifnecessary. The techniques used in this message processing and messagerouting are well known. In a preferred implementation, the MRPimplements a Web Service Routing Protocol (WS-Routing) that is currentlybeing developed by various World Wide Web (WWW) consortiums.

In a preferred implementation, the MRP adds destination routing data toeach query message and dynamically determines where the results of thequery will be sent.

A Plurality of Messages

The MRP processes a plurality of messages. These messages include systemgenerated maintenance requests; user generated lookup queries andadvertiser generated refresh requests.

Simple Keyword Lookup (KLU) message queries contain a keyword parameterand a specific localization parameter and are returned to the EDAApplication console. Position Control Refresh (PCR) messages contain akeyword parameter and instructions used to refresh the indexes in theListing Control Block 84. Local Data Refresh (LDR) queries containkeywords and refresh cycle time parameters and are returned to theLDSvr. The results of LDR queries are used to update the local cachedresults.

The MRP connects to a Listing Control Block 84 that contains aLocalization Index 86, a Keyword Index 88 and a Listing Position Controlindex 90. These indexes are used to control what keyword listings areselected and the order in which they are returned. The techniques ofdatabase indexing are well understood in the current art.

In a preferred implementation, the Listing Control Block applies filtersto the listing database and returns an ordered set of directorylistings. In a preferred implementation, the set of returned listings isan XML document in the well-known XML format. In another preferredimplementation, the set of returned listings is an extensible Hyper TextMarkup Language (XHTML) format.

The Listing Control Block connects to a Listing Database 91. The ListingDatabase contains the actual directory listing data. The composition oftelephone directory listing databases is well known in the art.Referring to FIG. 4, a preferred implementation contains an AccountInformation 92 block, a Business Category Control Structure 94 block anda Directory Listings 96 data storage block.

The Listing Database

The Listing Database of the preferred implementation supports all thedata operations required by the EDA Center. These operations includedatabase maintenance such as data backup and database optimization, andbusiness management operations such as account information management.The Listing Database also supports the operation of the EDA Service. Inthe preferred implementation under disclosure, the database maintenanceand business management operations follow standard practices accordingto the current art unless specifically detailed.

The database operations of the EDA Service are unique to the inventionunder disclosure and are detailed in FIG. 5.

FIG. 5 shows a system block diagram of the EDA Listing Database.Referring to FIG. 5, the Listing Database contains a collection ofdatabase tables that are serviced by a database engine. Database engineis technology is well understood in the current art.

The Listing Database of the preferred implementation contains an AccountInformation 200 table. The Account Information table containsinformation about EDA listing owners, business partners and Listingadvertisers. The information contained in the table includes AdvertiserNames 202, Contact Information 204 such as telephone numbers, andBilling Information 206.

The table also includes links to detailed Advertising Information 208.Included in the implementation is a link 210 to a set of DirectoryListings.

In a preferred implementation, the table of Directory Listings iscomposed of a unique identifying account number 242, Account Balanceentries 243, and one or a plurality of individual Directory Listings244, 246, 248.

In a preferred implementation, each Directory Listing is linked 250 toan individual Directory Listing record. Each listing record contains:

-   -   a list of Keywords 260 associated with the listing,    -   a Description 262; a Referral Phone Number 264,    -   a Business Role identifier 266 specifying the business process        that applies of the listing,    -   a Listing Message 268 that is read or played back,    -   a set of localization codes 270 that identifies the effective        locality of the listing,    -   position control data 272.

The position control data is used to specify a comparative ranking. Thisranking is used to determine the order in which the listings arereturned in the Get Listing procedure as detailed in FIG. 6.

The Get Listings Database Operation

FIG. 6 shows an operational flowchart of the operation of the ListingDatabase procedures in a preferred EDA LMSvr implementation.

Referring to FIG. 6, the Get Listings process of a preferredimplementation begins by executing a Get Query Parameters 352 process.The query includes a Query ID 354 parameter to identify the particularquery, a Keyword 356 parameter, a localization code 358 and a Timestamp360 for auditing purposes. The parameters are used to construct astandard ANSI SQL database query and executed by the Listing databaseengine as shown in Execute Query 362. The operation of SQL databaseengines are well known and well understood in the art.

The Listing database engine returns results as shown in block 364consisting of zero or more result rows 380. Each result row includesidentification fields: a Listing ID 366 to identify the listing, a QueryID 367 to identify the query, a Keyword ID 368 to identify the keyword,an Advertiser ID 370 to identify the listing owner. Each Row alsoinclude fields used to conduct the EDA Center Business: the PositionRank 372 number is used to determine the order of the listings, theBusiness Rule ID 374 specifies the accounting and business process usedto handle referrals. Finally each row also contains the actual listingwhich can be relayed to EDA Center customers; this includes the listingMessage Content 376, and a Referral Phone Number 378. The ListingDatabase of the LMSvr FIG. 1-40 connects to the LDSvr FIG. 1-50.

In a preferred implementation, the handling and business processspecified by the Business Rule ID determines how a referral is chargedback. The disclosed implementation allows for one or a plurality ofcharge back schemes or business models.

In a preferred implementation, an individual charge back ispredetermined by a contracted charge agreed on between the EDA Serviceprovider and the listing advertiser.

In a preferred implementation, the charge back is dynamically controlledand related to a customer satisfaction or any number of externalperformance criteria.

In a preferred implementation, the Distributed Transaction Terminal FIG.4-98 sends a transaction message to the Distributed Transaction inputFIG. 7-100 of the LDSvr.

FIG. 7 shows an overview of a preferred Enhanced Directory AssistanceListing Distribution Server implementation.

Transaction Activity Capture

The LDSvr collects or captures referral calls as detailed in the AcceptReferral process of FIG. 2-318.

In a preferred implementation, a referral is generated by the EDAoperator clicking on an HTML hyperlink that appears on the DisplayScreen FIG. 3-72 of the EDA Operator Position Station. The hyperlinkcontains HTML attribute-value pairs in the well-known HTML destinationURL format. The attribute-value pairs represent fields from a row of theReturn Results FIG. 6-364 table and include the Listing ID FIG. 6-366,the Query ID FIG. 6-367, the Keyword ID FIG. 6-368, the Advertiser ID,FIG. 6-370 and the BusRule ID FIG. 6-374.

In a preferred implementation, selecting a menu option in an InteractiveVoice Response (IVR) dialog generates a referral. The IVR dialog isgenerated using standard and well-known VXML programming. The dialogmenu options are dynamically constructed from the fields of a row fromthe Return Results FIG. 6-364 table and include the Listing ID FIG.6-366, the Query ID FIG. 6-367, the Keyword ID FIG. 6-368, theAdvertiser ID, FIG. 6-370 and the BusRule ID FIG. 6-374.

In a preferred implementation, a referral is a URL address withattribute-value parameters that completely identify the referrallisting. The said referral is in the form of an XML message andrepresents a unique transaction involving a telephone caller, a listingadvertiser and the EDA Service.

Referring to FIG. 7, the type of transaction message is identified bythe Distributed Transaction Router (DTR). The DTR recognizes a pluralityof transaction message types including Cache Refresh messages andActivity Capture messages. Cache Refresh messages are routed to theLocal Data Cache 110 (LDC) and Activity Capture messages are routed tothe Transaction Capture Block 120.

Local Data Cache

Referring to FIG. 7, the LDC operates in the manner of well-knowndistributed Internet caches that store pre-aggregated query results. Thequery results are organized by keyword and localization code. The datacontained in the LDC is tagged with an expiration date timestamp. Whenthe expiration timestamp is passed, the cache data is expired.

Upon expiration of data in the LDC, a refresh message is generated andsent to a Cache Refresh Processing 114 component (CRP). The refreshmessage is routed to the EDA Listing Management Input shown in FIG.4-80. The message contains a Keyword Lookup Query that is processed aspreviously described.

In a preferred implementation, the LDC is a plurality of data cacheservers organized as a distributed computing web farm.

Transaction Capture Block

Referring to FIG. 7, the Transaction Capture Block 120 includes theTransaction Activity Collector 122 component and the Multi-TransactionProcessing 124 component. The Transfer Capture Block receives ActivityCapture type transaction messages from the DTR. The message identifiesthe referral of an EDA listing to an EDA caller.

The operation of the Transaction Capture Block is unique to the EnhancedDirectory Assistance Service implementation and is detailed in FIG. 8.

Referring to FIG. 8, the Transaction Capture operation starts with theGet Transaction Parameters 400 process. In a preferred implementation, aminimal set of parameters is used to uniquely identify the query and theadvertiser the query belongs to. A minimal set of parameters includes aTransaction ID 402 that uniquely identifies the referral, a Query ID 404that uniquely identifies the contents of the referral, a BusRule ID 406that specifies the business process that governs the referral and aTimestamp 408.

Once the data is assembled, a transaction record uniquely identifyingthe referral is inserted into a Listing database transaction table inthe Record Transaction 420 process. The data from this record is thenprocessed. This processing is the primary focus of the TransactionCapture operation.

The Get Advertiser Data 424 and the Get Business Rule Data 426 processesset up transactions for the EDA Center accounting system. The GetAdvertiser Data operation gets the Advertiser ID and Account Number ofthe referred directory listing. The Get Business Rule Data operationidentifies and sets up the business process and pricing rules thatgovern this particular transaction.

Once the referral parties and the referral business rules areidentified, accounting transactions are created and posted to the EDACenter accounting system via the Accounting Interface 430.

The operation of this type account system is well known and wellunderstood. The generation of multiple and distinct businesstransactions for a single telephone referral is one of the uniqueprocesses of this disclosure.

Other Data

The Collect Data 422 process aggregates any necessary data forconducting marketing and sales analysis. This data is then sent to theanalysis systems via a Data Analysis Interface 423. Similarly, the UseData 432 process aggregates and collects data for use by other systemsthat are well known in the art such as Customer Relations Managementsystems. This data is sent via the Other Business Interface 434.

Although exemplary embodiments of the present invention have been shownand described, it will be apparent to those having ordinary skill in theart that a number of changes, modifications, or alterations to theinvention as described herein may be made, none of which depart from thespirit of the present invention. All such changes, modifications andalterations should therefore be seen as within the scope of the presentinvention.

It is claimed:
 1. A method for maintaining a dynamically controlledindex for a telephone directory assistance system comprising: undercontrol a client system, presenting telephone directory informationlistings, ordering the listings with a plurality indexes, allowing forthe listings to be dynamically controlled, allowing for the indexes tobe dynamically controlled.
 2. The method of claim 1 wherein thedynamically controlled index is a keyword associated with the listingcontent.
 3. The method of claim 1 wherein the dynamically controlledindex is a location code associated with the listing content.
 4. Themethod of claim 1 wherein the dynamically controlled index is a businesscategory code associated with the listing content.
 5. The method ofclaim 1 wherein the dynamically controlled index is a referral paymentamount negotiated between the listing owner and the listing provider. 6.A method of generating a list of phone numbers substantially in realtime in response to a directory assistance request from a telephonecustomer using a computer network comprising: maintaining a databaseincluding a plurality of directory listings, wherein each listing isassociated with a referral phone number, at least one search term and adynamic, controllable index; receiving a directory assistance request inthe form of a keyword from the customer; identifying the directorylistings having keyword terms generating a match with the request;ordering the identified directory listings into a phone number resultlist in accordance with the values of some controllable index for theidentified directory listings; receiving an acceptance request from thecustomer to retrieve information associated with a directory listing inthe result list; relaying the reprieved information with a directorylisting in the result list to the customer; connecting the customer tothe referral phone number from the retrieved information with adirectory listing; and recording a retrieval request event includingaccount identification information corresponding to the listing owner,to permit maintenance of accurate account debit records.